Hi, On 2022-08-01 10:07:32 +1200, Thomas Munro wrote: > > > I suspect it'd be better to remove the minor version numbers from the > > > image name, so that switches from 13.0 -> 13.1 don't require CI > > > changes. Any argument against? > > Yeah, that makes sense; it'd remove the need for commits like that. > For comparison, the Debian image is Bullseye AKA 11.x without the x in > the name. Cool, doing that in https://github.com/anarazel/pg-vm-images/pull/15 There's now "freebsd-13" and "netbsd-9-postgres", "openbsd-7-postgres". The latter two include the -postgres because we have to generate the "base" image ourselves, because neither net nor openbsd provide a gcp image themselves. Not that we use net/openbsd images in PG itself yet (I'm about to merge open/netbsd support in the meson branch though). > > > I can also see an argument for not having 13 in the image name, given > > > that the image is CI specific anyway? But perhaps we might want to have > > > a 13 and a 14 image for some debugging issue? > > I'm not sure about this. I could imagine a naming scheme that has > sensible options available as pg-ci-{debian,freebsd,...}-default, and > those images are currently the same as > pg-ci-{debian-11,freebsd-13,...} but can be re-pointed as appropriate > without having to modify the .cirrus.yml, and someone investigating a > problem where they really care about the major version could change > their .cirrus.yml to point to the versioned name. There's such a concept for gcp, namely "image families". But we already use that for pg-ci-bullseye etc - each individual image has a name including the date. There's only one level of families afaiu. We of course could manually copy images, but that's probably not worth it (and would come with storage costs). E.g. pg-ci-bullseye currently points to pg-ci-bullseye-2022-07-31t21-31. > I don't have a concrete example, but I have a strange feeling in my big toe > that it'd be better to state the major version explicitly, and have a few > available... FWIW, at the moment all images are deleted after two weeks ([1]). We probably can make that smarter and not delete the newest image for a family, even if that image is older than two weeks. Not that the gcp API seems to make that easy. Greetings, Andres Freund [1] https://github.com/anarazel/pg-vm-images/blob/main/.cirrus.yml#L209

On Thu, 28 Jul 2022 at 19:31, Andres Freund <andres@anarazel.de> wrote: > > Hi, > > On July 28, 2022 7:29:43 PM GMT+02:00, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > >On Thu, 28 Jul 2022 at 11:57, Andres Freund <andres@anarazel.de> wrote: > >> > >> Hi, > >> > >> Freebsd 13.0, so far used by CI, is out of support. I've changed the > >> image to be built against 13.1, so we can switch to that. > >> > >> I suspect it'd be better to remove the minor version numbers from the > >> image name, so that switches from 13.0 -> 13.1 don't require CI > >> changes. Any argument against? > >> > >> I can also see an argument for not having 13 in the image name, given > >> that the image is CI specific anyway? But perhaps we might want to have > >> a 13 and a 14 image for some debugging issue? > > > >Has this change in the BSD configuration been applied today? I see > >failures in the cfbot builds of 4 different patches [0..3] that all > >fail in 033_replay_tsp_drops.pl with the same output: > > No, this hasn't yet been applied. > > ># poll_query_until timed out executing this query: > ># SELECT '0/40EAXXX' <= replay_lsn AND state = 'streaming' > ># FROM pg_catalog.pg_stat_replication > ># WHERE application_name IN ('standby2_WAL_LOG', 'walreceiver') > ># expecting this output: > ># t > ># last actual query output: > ># > ># with stderr: > ># Tests were run but no plan was declared and done_testing() was not seen. > ># Looks like your test exited with 29 just after 1. > >t/033_replay_tsp_drops.pl ............ > >Dubious, test returned 29 (wstat 7424, 0x1d00) > >All 1 subtests passed > > That seems more likely related to the recent changes in this area. Hmm, I should've looked further than just this, so I would've realised that this was a new test. I guess I'll go bother Alvaro on the relevant thread instead. Thanks for the quick response. Kind regards, Matthias van de Meent